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Lightweight Directory Access Protocol (LDAP) 
Modify-Increment Extension 


Status of This Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document describes an extension to the Lightweight Directory 
Access Protocol (LDAP) Modify operation to support an increment 
capability. This extension is useful in provisioning applications, 


especially when combined with the assertion control and/or the pre- 
read or post-read control extension. 
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1. Background and Intended Use 


The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not 
currently provide an operation to increment values of an attribute. 
A client must read the values of the attribute and then modify those 
values to increment them by the desired amount. As the values may be 
updated by other clients between this add and modify, the client must 
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be careful to construct the modify request so that it fails in this 
case, and upon failure, to re-read the values and construct a new 
modify request. 


This document extends the LDAP Modify Operation [RFC4511] to support 
an increment values capability. This feature is intended to be used 
with either the LDAP pre-read or post-read control extensions 


[RFC4527]. This feature may also be used with the LDAP assertion 
control extension [RFC4528] to provide test-and-increment 
functionality. 


In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]. 


2. The Modify-Increment Extension 


This document extends the LDAP Modify request to support a increment 
values capability. Implementations of this extension SHALL support 
an additional ModifyRequest operation enumeration value increment 
(3), as described herein. Implementations not supporting this 
extension will treat this value as they would an unlisted value, 
e.g., as a protocol error. 


The increment (3) operation value specifies that an increment values 
modification is requested. All existing values of the modification 
attribute are to be incremented by the listed value. The 
modification attribute must be appropriate for the request (e.g., it 
must have INTEGER or other increment-able values), and the 
modification must provide one and only one value. If the attribute 
is not appropriate for the request, a constraintViolation or other 
appropriate error is to be returned. If multiple values are 
provided, a protocolError is to be returned. 


Servers supporting this feature SHOULD publish the object identifier 
(OID) 1.3.6.1.1.14 as a value of the ’supportedFeatures’ [RFC4512] 
attribute in the root DSE. Clients supporting this feature SHOULD 
NOT use the feature unless they know the server supports it. 


3. LDIF Support 
To represent Modify-Increment requests in LDAP Data Interchange 
Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is 


extended as follows: 


mod-spec =/ "“increment:" FILL AttributeDescription SEP 
attrval-spec "-" SEP 
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For example, 


# Increment uidNumber 

dn: cn=max-assigned uidNumber, dc=example, dc=com 
changetype: modify 

increment: uidNumber 

uidNumber: 1 


This LDIF fragment represents a Modify request to increment the 
value(s) of uidNumber by 1. 


Security Considerations 


General LDAP security considerations [RFC4510], as well as those 
specific to the LDAP Modify [RFC4511], apply to this Modify-Increment 
extension. Beyond these considerations, it is noted that 
introduction of this extension should reduce application complexity 
(by providing one operation for what presently requires multiple 
operations) and, hence, it may aid in the production of correct and 
secure implementations. 


IANA Considerations 
Registration of the following values [RFC4520] have been completed. 
1. Object Identifier 


The IANA has assigned an LDAP Object Identifier to identify the LDAP 
Modify-Increment feature, as defined in this document. 


Subject: Request for LDAP Object Identifier Registration 
Person & email address to contact for further information: 
Kurt Zeilenga <kurt@OpenLDAP.org> 
Specification: RFC 4525 
Author/Change Controller: Author 
Comments: 
Identifies the LDAP Modify-Increment feature 


-2. LDAP Protocol Mechanism 


The following LDAP Protocol Mechanism has been registered. 


Subject: Request for LDAP Protocol Mechanism Registration 

Object Identifier: 1.3.6.1.1.14 

Description: Modify-Increment 

Person & email address to contact for further information: 
Kurt Zeilenga <kurt@openldap.org> 
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Usage: Feature 

Specification: RFC 4525 

Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> 
Comments: none 


5.3. LDAP Protocol Mechanism 


The IANA has assigned an LDAP ModifyRequest Operation Type (3) 
[RFC4520] for use in this document. 


Subject: Request for LDAP Protocol Mechanism Registration 

ModifyRequest Operation Name: increment 

Description: Modify-Increment 

Person & email address to contact for further information: 
Kurt Zeilenga <kurt@openldap.org> 

Usage: Feature 

Specification: RFC 4525 

Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> 

Comments: none 
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Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is provided by the IETF 
Administrative Support Activity (IASA). 


Zeilenga Informational [Page 6] 


